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Software  Engineering  Institute 


Applied  R&D  laboratory  situated  as  a 
college-level  unit  at  Carnegie  Mellon 
University,  Pittsburgh,  PA,  USA 


Established  in  1984 


Technical  staff  of  335 

Offices  in  Pittsburgh,  Pennsylvania 
Arlington,  Virginia  (USA)  and 
Frankfurt  Germany 

Purpose:  Help  others  improve 
their  software  engineering 
practices 
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Product  Line  Systems  Program 

Our  Goal:  To  enable  widespread  product  line 
practice  through  architecture-centric 
development 
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-  -=3"  Software  Engineering  Institute 

Our  Strategy 

Software  Architecture 

(Software  Architecture  Technology 
Initiative) 

Software  Product  Lines 

(Product  Line  Practice  Initiative) 

Component  Technology 

(Predictable  Assembly  from  Certifiable 
Components  Initiative) 
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Business  Success  Requires 
Software  Prowess 


Software  pervades  every  sector. 

Software  has  become  the  bottom  line  for 
many  organizations  who  never  envisioned 
themselves  in  the  software  business. 
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Business  Goals 

High  quality 
Quick  time  to  market 
Effective  use  of  limited  resources 

Product  alignment 
Low  cost  production 
Low  cost  maintenance 
Mass  customization 
Mind  share 
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The  Ultimate  Universal  Goal 
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Software  Strategies  Are  Needed 


Business  Goals 


Improvement 
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Software  Architecture:  Common  Ideas 

A  software  architecture  is  a  “first-cut”  at  designing  the 
system  and  solving  the  problem  or  fitting  the  need. 

A  software  architecture  is  an  ad  hoc  box-and-line 
drawing  of  the  system  that  is  intended  to  solve  the 
problems  articulated  by  the  specification. 

•  Boxes  define  the  elements  or  “parts”  of  the  system. 

•  Lines  define  the  interactions  or  between  the  parts. 
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Carnegie  Mel  lou 
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Our  Definition  of  Software 
Architecture 

“  The  software  architecture  of  a  program  or 
computing  system  is  the  structure  or  structures 
of  the  system,  which  comprise  software 
elements,  the  externally  visible  properties  of 
those  elements,  and  the  relationships  among 
them.” 


Bass  L.;  Clements  P.;  Kazman  R.  Software  Architecture  in  Practice 
2nd  Edition  Reading,  MA:  Addison-Wesley,  2003. 
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Implications  of  Our  Definition 

Architecture  is  an  abstraction  of  a  system. 

Systems  can  and  do  have  many  structures. 

Every  system  has  an  architecture. 

Just  having  an  architecture  is  different  from  having  an 
architecture  that  is  known  to  everyone. 

If  you  don’t  explicitly  develop  an  architecture,  you  will  get 
one  anyway  -  and  you  might  not  like  what  you  get! 
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Why  is  Software  Architecture  Important? 


Represents  earliest  design  decisions 


First  design  artifact  addressing 


Key  to  systematic  reuse 


hardest  to  change 
most  critical  to  get  right 
communication  vehicle  among 
stakeholders 


performance  •  modifiability 
reliability  •  security 


transferable,  reusable  abstraction 


The  right  architecture  paves  the  way  for  system  success. 
The  wrong  architecture  usually  spells  some  form  of  disaster. 
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Requirements  Beget  Design 
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Software  System  Development 
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System  Qualities  and  Software 
Architecture 
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Architecture  and  Functionality 

Functionality  is  largely  orthogonal  to  quality  attribute 
requirements. 

•  Functionality  is  the  ability  of  a  system  to  do  the  work  it 
was  intended  to  do. 

•  Systems  are  decomposed  into  elements  to  achieve  a 
variety  of  purposes  other  than  function. 

-  Architectural  choices  promote  certain  qualities  as  well 
as  implement  the  desired  functionality. 
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Carnegie  Mellon 
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Effects  of  Architectural  Decisions 
on  Quality  Attributes 

The  degree  to  which  a  system  meets  it’s  quality  attribute 
requirements  is  dependent  on  architectural  decisions. 

•  A  change  in  structure  improving  one  quality  often  affects 
the  other  qualities. 

•  Architecture  is  critical  to  the  realization  of  quality 
attributes. 

•  These  product  qualities  should  be  designed  into  the 
architecture. 

•  Architecture  can  only  permit,  not  guarantee,  any  quality 
attribute. 
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Challenges 

What  precisely  do  these  quality  attributes  such  as 
modifiability,  security,  performance,  and  reliability  mean? 

How  do  you  architect  to  ensure  the  system  will  have  its 
desired  qualities? 

Can  a  system  be  analyzed  to  determine  these  desired 
qualities? 

How  soon  can  such  an  analysis  occur? 

How  do  you  know  if  software  architecture  for  a  system  is 
suitable  without  having  to  build  the  system  first? 
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Carnegie  Mellon 
Software  Engineering  Institute 

Quality  Attribute  Scenarios  -  1 

A  solution  to  the  problem  of  describing  quality  attributes 
is  to  use  quality  attribute  scenarios  as  a  means  to  better 
characterize  quality  attributes. 

A  quality  attribute  scenario  consists  of  six  parts. 


©  2004  by  Carnegie  Mellon  University 


page  24 


Carnegie  Mellon 
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Quality  Attribute  Scenarios  -  2 

1 .  stimulus  -  a  condition  that  affects  the  system 

2.  response  -  the  activity  that  results  because  of  the 
stimulus 

3.  source  of  the  stimulus  -  the  entity  that  generated  the 
stimulus 

4.  environment  -  the  condition  under  which  the  stimulus 
occurred 

5.  artifact  stimulated  -  the  artifact  that  was  stimulated  by 
the  stimulus 

6.  response  measure  -  the  measure  by  which  the 
system’s  response  will  be  evaluated 
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Parts  of  a  Quality  Attribute 
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General  and  Concrete  Scenarios 

General  scenarios 

•  are  those  scenarios  that  are  system  independent 

•  represent  quality  attribute  characterizations 

•  can  be  used  to  create  concrete  scenarios  that  are  specific 
to  a  particular  system. 

General  six-part  scenarios  exist  for 

•  availability 

•  modifiability 

•  performance 

•  security 

•  testability 

•  usability 
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Modifiability  - 1 

Definition:  Modifiability  is  about  the  cost  of  change  and 
refers  to  the  ease  with  which  a  software  system  can 
accommodate  changes. 

Areas  of  concern  include 

•  identifying  what  can  change 

-  functions,  platforms,  hardware,  operating  systems, 
middleware,  systems  it  must  operate  with,  protocols, 
and  so  forth 

-  quality  attributes:  performance,  reliability,  future 
modifiability,  and  so  forth 

•  When  will  the  change  be  made  and  who  will  make  it? 
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Modifiability  -  2 


General  scenario  considerations: 


Source 

End  user,  developer,  system  administrator 

Stimulus 

Add/delete/modify  functionality  or  quality 
attribute 

Environment 

Runtime,  compile  time,  build  time,  design 
time 

Artifacts 

System:  user  interface,  platform, 
environment,  system  that  interoperates 
with  target  system 

©  2004  by  Carnegie  Mellon  University 


page  29 


Carnegie  Mellon 
Software  Engineering  Institute 

Modifiability  -  3 


General  scenario  considerations  (continued): 


Response 

•Locate  places  in  the  architecture  to  be 
modified. 

•Make  modifications  without  affecting  other 
functionality. 

•Test  the  modification  with  minimal  effort. 

•Deploy  the  modification  with  minimal  effort. 

Response 

Measure 

•Cost  in  terms  of  the  number  of  affected 
components,  effort,  and  money 

•Extent  to  which  this  modification  affects  other 
functions  and/or  quality  attributes 
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Sample  Modifiability  Scenario 


A  developer  wishes  to  change  the  user  interface  (Ul)  code 
at  design  time.  The  modification  is  made  with  no  side 
effects,  in  three  hours. 


Source 

Developer 

Stimulus 

Wishes  to  change  the  Ul 

Artifact 

Code 

Environment 

At  design  time 

Response 

Modification  is  made  with  no  side  effects 

Response 

Measure 

In  three  hours 
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The  Reality  About  Software 
Architecture. 

Quality  attribute  requirements  are  the  primary  drivers  for 
architectural  design. 


The  degree  to  which  a  system  meets  its  quality  attribute 
requirements  is  dependent  on  architectural  decisions. 


Software  development  needs  to  be  driven  by  architectural 
decisions. 


Architecture-centric  development  is  key. 
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-  =3-  Software  Engineering  Institute 

What  is  architecture-centric 
development? 

Architecture-centric  development  involves 

•  Creating  the  business  case  for  the  system 

•  Understanding  the  requirements 

•  Creating  or  selecting  the  architecture 

•  Documenting  and  communicating  the 
architecture 

•  Analyzing  or  evaluating  the  architecture 

•  Implementing  the  system  based  on  the 
architecture 

•  Ensuring  that  the  implementation 
conforms  to  the  architecture 

•  Maintaining  the  architecture 


The  architecture  must  be  both 
prescriptive  and  descriptive. 


Carnegie  Mellon 
Software  Engineering  Institute 

Influence  of  System  Stakeholders  - 1 

Stakeholders  have  an  interest  in  the  construction  of  a 
software  system.  Stakeholders  might  include 

•  customers 

•  users 

•  developers 

•  project  managers 

•  marketers 

•  maintainers 

Stakeholders  have  different  concerns  that  they  wish  to 
guarantee  and/or  optimize. 
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Influence  of  System  Stakeholders  -  2 
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Stakeholder  Involvement 

The  organizational  goals  and  the  system  properties  required 
by  the  business  are  rarely  understood,  let  alone  fully 
articulated. 

Customer  quality  attribute  requirements  are  seldom 

documented,  which  results  in 

•  goals  not  being  achieved 

•  inevitable  conflict  between  different  stakeholders 

Architects  must  identify  and  actively  engage  stakeholders  in 
order  to 

•  understand  real  constraints  of  the  system 

•  manage  the  stakeholders’  expectations 

•  negotiate  the  system’s  priorities 

•  make  tradeoffs 
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SEI  Work  in  Software  Architecture: 


Maturing  Sound  Architecture  Practices 


Starting  Points 


Quality  attribute/ 

performance 

engineering 

Software  Architecture 
Analysis  Method 
(SAAM) 

Security  analysis 

Reliability  analysis 

Software  Architecture 
Evaluation  Best 
Practices  Report 

Software  architecture 
evaluations 


Create 

Technology 

Attribute-specific 

patterns 

Architecture  expert 

Life  Cycle  Practices 

•  Architectural 
requirements 
elicitation 
Architecture 
definition 

•  Architecture 
representation 

•  Architecture 
evaluation 

•  Architecture 
reconstruction 
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What  is  architecture-centric 
development? 

Architecture-centric  development  involves 

•  Creating  the  business  case  for  the  system 

•  Understanding  the  requirements 

•  Creating  or  selecting  the  architecture 

•  Documenting  and  communicating  the 
architecture 

•  Analyzing  or  evaluating  the  architecture 

•  Implementing  the  system  based  on  the 
architecture 

•  Ensuring  that  the  implementation 
conforms  to  the  architecture 

•  Maintaining  the  architecture 


The  architecture  must  be  both 
prescriptive  and  descriptive. 


■■  Carnegie  Mellon 

Software  Engineering  Institute 


Traditional  System  Development 


Operational  descriptions 
High  level  functional  requirements 
Legacy  systems 
New  systems 


Specific  system  architecture 
Software  architecture 


Quality  attributes  are  rarely 
captured  in  requirements 
specifications. 

•  often  vaguely  understood 

•  often  weakly  articulated 


Detailed  design 
Implementation 
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Quality  Attribute  Workshop 


The  Quality  Attribute  Workshop  (QAW)  is  a  facilitated 
method  that  engages  system  stakeholders  early  in  the 
lifecycle  to  discover  the  driving  quality  attributes  of  a 
software  intensive  system. 


Key  points  about  the  QAW  are  that  it  is 

•  system  centric 

•  scenario  based 

•  stakeholder  focused 

•  used  before  the  software  architecture  has  been  created 
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Quality  Attribute  Workshop  Steps 

1.  Introductions  and  QAW  Presentation  < - 

2.  Business/Mission  Presentation 

3.  Architecture  Plan  Presentation 

4.  Identify  Architectural  Drivers 

5.  Scenario  Brainstorming 

6.  Scenario  Consolidation 

7.  Scenario  Prioritization 

8.  Scenario  Refinement  - 

Iterate  as  necessary  with  broader 

stakeholder  community 
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QAW  Benefits  and  Next  Steps 


QAW 

Quality 

Attribute 

Scenarios: 

•  raw 

•  prioritized 

•  refined 

13 


Potential  Next  Steps 

Update  Architectural  Vision 
Refine  Requirements 
Create  Prototypes 
Exercise  Simulations 


usecPto  Create  Architecture 


j 


Potential  Benefits 

•  Increased  stakeholder  communication 

•  Clarified  quality  attribute  requirements 

•  Informed  basis  for  architectural  decisions 


Architecture 
Evaluation 
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What  Is  Architecture-centric 
Development? 

Architecture-centric  development  involves 

•  Creating  the  business  case  for  the  system 

•  Understanding  the  requirements 

•  Creating  or  selecting  the  architecture 

•  Documenting  and  communicating  the 
architecture 

•  Analyzing  or  evaluating  the  architecture 

•  Implementing  the  system  based  on  the 
architecture 

•  Ensuring  that  the  implementation 
conforms  to  the  architecture 

•  Maintaining  the  architecture 

The  architecture  must  be  both 
prescriptive  and  descriptive. 


Carnegie  Mellon 
Software  Engineering  Institute 

Creating  the  Software  Architecture 

There  are  architecture  definition  methods  and  guidelines, 
many  of  which  focus  exclusively  on  the  functional 
requirements. 

It  is  possible  to  create  an  architecture  based  on  the  quality 
architectural  drivers. 

One  way  to  approach  this  is  to  use  architectural  tactics 
and  patterns  and  a  method  that  capitalizes  on  both. 
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Tactics 

The  design  for  a  system  consists  of  a  collection  of  design 

decisions. 

•  Some  decisions  are  intended  to  ensure  the  achievement 
of  the  functionality  of  the  system. 

•  Other  decisions  are  intended  to  help  control  the  quality 
attribute  responses. 

These  decisions  are  called  tactics. 

•  A  tactic  is  a  design  decision  that  is  influential  in  the 
control  of  a  quality  attribute  response. 

•  A  collection  of  tactics  is  an  architectural  strategy. 
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Tactics  Catalog 

Tactics  have  been  defined  for  the  following  quality 
attributes: 

•  Performance 

•  Availability 

•  Maintainability 

•  Usability 

•  Testability 

•  Security 

Others  are  in  the  works. 
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Performance  Tactics 


Summary  of  performance  tactics 
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Attribute-Driven  Design 

The  Attribute-Driven  Design  (ADD)  method,  developed  at 
the  SEI,  is  an  approach  to  defining  a  software  architecture 
that  bases  the  decomposition  process  on  the  quality 
attributes  the  software  must  fill. 

It  follows  a  recursive  decomposition  process  where,  at 
each  stage  in  the  decomposition,  tactics  and  architectural 
patterns  are  chosen  to  satisfy  a  set  of  quality  scenarios. 
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Evolutionary  Delivery  Life  Cycle 
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ADD  Method's  Inputs  and  Outputs 


Inputs 

•  constraints 

•  functional  requirements 

•  quality  attribute  requirements 
Outputs 

•  first  several  levels  of  module  decomposition 

•  various  other  views  of  the  system  as  appropriate 

•  set  of  elements  for  functionality  and  the  interactions 
among  them 
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What  Is  Architecture-centric 
Development? 

Architecture-centric  development  involves 

•  Creating  the  business  case  for  the  system 

•  Understanding  the  requirements 

•  Creating  or  selecting  the  architecture 

•  Documenting  and  communicating  the 
architecture 

•  Analyzing  or  evaluating  the  architecture 

•  Implementing  the  system  based  on  the 
architecture 

•  Ensuring  that  the  implementation 
conforms  to  the  architecture 

•  Maintaining  the  architecture 

The  architecture  must  be  both 
prescriptive  and  descriptive. 
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Importance  of  Architecture 
Documentation 

Architecture  documentation  is  important  if  and  only  if 
communication  of  the  architecture  is  important. 

•  How  can  an  architecture  be  used  if  it  cannot  be 
understood? 

•  How  can  it  be  understood  if  it  cannot  be 
communicated? 

Documenting  the  architecture  is  the  crowning  step  to 
creating  it. 

Documentation  speaks  for  the  architect,  today  and  20 
years  from  today. 
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Seven  Principles  of  Sound 
Documentation 

Certain  principles  apply  to  all  documentation,  not  just 
documentation  for  software  architectures. 

1 .  Write  from  the  point  of  view  of  the  reader. 

2.  Avoid  unnecessary  repetition. 

3.  Avoid  ambiguity. 

4.  Use  a  standard  organization. 

5.  Record  rationale. 

6.  Keep  documentation  current  but  not  too  current. 

7.  Review  documentation  for  fitness  of  purpose. 
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Views 

A  view  is  a  representation  of 
a  set  of  system  elements  and 
the  relations  associated  with 
them. 

Not  all  system  elements,  some 
of  them. 

A  view  binds  an  element  type 
and  relation  type  of  interest, 
and  illustrates  them. 
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View-Based  Documentation 


Views  give  us  our  basic  principle  of  architecture 
documentation: 


Documenting  a  software  architecture  is  a  matter  of 
documenting  the  relevant  views,  and  then  adding 
information  that  applies  to  more  than  one  view. 
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Which  Views  Are  Relevant? 


Which  views  are  relevant?  It  depends  on 

•  who  the  stakeholders  are 

•  how  they  will  use  the  documentation 

Three  primary  uses  for  architecture  documentation  are 


1 .  education  -  introducing  people  to  the  project 

2.  communication  -  among  stakeholders 

3.  analysis  -  assuring  quality  attributes 
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What  Is  Architecture-centric 
Development? 

Architecture-centric  development  involves 

•  Creating  the  business  case  for  the  system 

•  Understanding  the  requirements 

•  Creating  or  selecting  the  architecture 

•  Documenting  and  communicating  the 
architecture 

•  Analyzing  or  evaluating  the  architecture 

•  Implementing  the  system  based  on  the 
architecture 

•  Ensuring  that  the  implementation 
conforms  to  the  architecture 

•  Maintaining  the  architecture 

The  architecture  must  be  both 
prescriptive  and  descriptive. 
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Traditional  System  Development 
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A  Critical  leap! 
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Why  Evaluate  Architectures? 

All  design  involves  tradeoffs. 

A  software  architecture  is  the  earliest  life-cycle  artifact  that 

embodies  significant  design  decisions  and  tradeoffs. 

•  The  earlier  that  risks  are  identified,  the  earlier  that 
mitigation  strategies  can  be  developed  potentially  avoid 
the  risks  altogether. 

•  The  earlier  that  defects  are  found,  the  less  it  costs  to 
remove  them. 
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SEI’s  Architecture  Tradeoff  Analysis 

MethodSM  (ataM)sm 

ATAM  is  an  architecture  evaluation  method  that 

•  focuses  on  multiple  quality  attributes 

•  illuminates  points  in  the  architecture  where  quality 
attribute  tradeoffs  occur 

•  generates  a  context  for  ongoing  quantitative  analysis 

•  utilizes  an  architecture’s  vested  stakeholders  as 
authorities  on  the  quality  attribute  goals 


©  2004  by  Carnegie  Mellon  University 


page  61 


Carnegie  Mellon 

Software  Engineering  Institute 

The  ATAMSM 


The  SEI  has  developed  the  Architecture 
Tradeoff  Analysis  MethodSM  (ATAMSM). 

The  purpose  of  ATAM  is:  to  assess  the 
consequences  of  architectural  decisions  in  light 
of  quality  attribute  requirements  and  business 
goals. 
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Purpose  of  ATAM  -  1 

The  ATAM  is  a  method  that  helps  stakeholders 
ask  the  right  questions  to  discover  potentially 
problematic  architectural  decisions 

Discovered  risks  can  then  be  made  the  focus  of 
mitigation  activities:  e.g.  further  design,  further 
analysis,  prototyping. 

Surfaced  tradeoffs  can  be  explicitly  identified  and 
documented. 
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Purpose  of  ATAM  -  2 

The  purpose  of  the  ATAM  is  NOT  to  provide 
precise  analyses  ...  the  purpose  IS  to  discover 
risks  created  by  architectural  decisions. 

We  want  to  find  trends :  correlation  between 
architectural  decisions  and  predictions  of 
system  properties. 
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ATAM  Phases 


ATAM  evaluations  are  conducted  in  four  phases. 


Duration:  varies 
Meeting:  primarily 
phone,  email 


Duration:  1.5-2  days  each  for  Duration:  varies 
Phase  1  and  Phase  2  Meeting:  primarily 

Meeting:  typically  conducted  phone,  email 
at  customer  site 
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ATAM  Steps 


1 .  Present  the  ATAM 

2.  Present  business  drivers 

3.  Present  architecture 

4.  Identify  architectural  approaches 

5.  Generate  quality  attribute  utility  tree 

6.  Analyze  architectural  approaches 

7.  Brainstorm  and  prioritize  scenarios 

8.  Analyze  architectural  approaches 

9.  Present  results 
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Example  Utility  Tree 


Performance 


Modifiability 


Availability 


Security 


-C 


(M  L)  Reduce  storage  latency  on 
Data  i—  customer  DB  to  <  200  ms. 

Latency 


(H,M) 


Transaction 

Throughput 


Deliver  video  in  real  time 


New  product 
categories 

Change  — 
COTS 


HA N  failure 

COTS  S/W 
failures 


(L,H) 

(M,M) 

(H.M) 


Add  CORBA  middleware 
in  <  20  person-months 

Change  web  user  interface 
in  <  4  person-weeks 

Power  outage  at  sitel  requires  traffic 
redirected  to  site2  in  <  3  seconds. 

Restart  after  disk  failure  in  <  5  minutes 

Network  failure  detected  and  recovered 
in  <  1 .5  minutes 


(L,H) 


Data 

confidentiality 

Data 

integrity 


Credit  card  transactions  are  secure 
99.999%  of  the  time 
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Conceptual  Flow  of  the  ATAM^ _ 
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When  to  Use  the  ATAM 

The  ATAM  can  be  used  throughout  the  life  cycle  when 
there  is  a  software  architecture  to  evaluate. 

The  ATAM  can  be  used 

•  after  an  architecture  has  been  specified  but  there  is 
little  or  no  code 

•  to  evaluate  architectural  alternatives 

•  to  evaluate  the  architecture  of  an  existing  system 

To  perform  an  ATAM  evaluation,  there  must  be  a  software 
architecture  to  evaluate. 

•  An  ATAM  evaluation  is  inappropriate  if  the  software 
architecture  of  the  system  has  not  been  created  yet. 
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ATAM  Benefits 

The  benefits  of  performing  ATAM  evaluations  include 

•  clarified  quality  attribute  requirements 

•  improved  architecture  documentation 

•  documented  basis  for  architectural  decisions 

•  identification  of  risks  early  in  the  life  cycle 

•  increased  communication  among  stakeholders 

The  result  is  improved  architectures. 
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Architecture  Evaluation  Experience 

Benefits  of  early  architecture  evaluations 

•  Evaluations  using  the  Architecture  Tradeoff  Analysis 
MethodSM  (ATAMSM)  uncover  an  average  20  risks  per 
two-day  evaluation.  Experience  over  a  wide  range  of 
domains  attributes  these  risks  to 

•  unknowns  (requirements,  hardware,  COTS) 

•  side  effects  of  architectural  decisions 

•  improper  architectural  decisions 

•  interactions  with  other  organizations  that  provide 
system  components 

•  Evaluations  performed  by  AT&T  have  resulted  in  10% 
productivity  increase  per  project 
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Software  Architecture  Practices 

SEI  Software  Architecture  Support 
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SEI  Work  in  Software  Architecture: 
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SEI  Software  Architecture  Curriculum 


Six  courses 

•  Software  Architecture:  Principles  and  Practices 

•  Documenting  Software  Architectures 

•  Software  Architecture  Design  and  Analysis 

•  Software  Product  Lines 

•  ATAM  Evaluator  Training 

•  ATAM  Facilitator  Training 

Three  certificate  programs 

•  Software  Architecture  Professional 

•  ATAM  Evaluator 

•  ATAM  Lead  Evaluator 

Coming  in  2005:  SEI  Software  Product  Line  Curriculum 
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About  the  Curriculum 

Software  professionals  can  take  individual  courses 
based  on  specific  needs  or  interests 
or  complete  one  or  more  of  the  following  three 
specially  designed  certificate  programs: 

•  Software  Architecture  Professional 

•  ATAMSM  Evaluator 

•  ATAMSM  Lead  Evaluator 

The  ATAM  certificate  programs  qualify  individuals  to 
perform  or  lead  SEI-authorized  ATAM  evaluations. 
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Certificate  Program  Course  Matrix 
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About  all  the  Courses 

All  of  the  courses  are  two-day  learning  experiences 
that  involve  lectures  and  exercises. 

The  materials  provided  include  books  and  class 
lecture  slides. 

Prerequisites  are  enforced. 

Any  of  the  courses  can  also  be  scheduled  for  on  site 
delivery. 
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Associated  Texts 


Software  Architecture  in 
Practice ,  2nd  Edition 


Documenting  Software 
Architectures:  Views 
and  Beyond 


Evaluating  Software 
Architectures:  Methods 
and  Case  Studies 


Software  Product  Lines: 
Practices  and  Patterns 
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SEI  Software  Architecture  Workshop 
for  Educators 

August  16-18,  2004 
Pittsburgh,  PA 

The  Software  Architecture  Workshop  for  Educators  is 
a  three-day  forum  for  sharing  SEI  software 
architecture  technology  with  educators  and  for  jointly 
determining  ways  to  incorporate  these  concepts  and 
methods  into  academic  courses. 

Schedule:  Aug  16-17:  Software  Architecture:  Principles 

and  Practices  Course 
Aug  18:  Facilitated  Discussion 
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Architecture  Principles 

Software  architecture  is  important  because  it 

•  provides  a  communication  vehicle  among  stakeholders 

•  is  the  result  of  the  earliest  design  decisions 

•  is  a  transferable,  reusable  abstraction  of  a  system 

The  degree  to  which  a  system  meets  its  quality  attribute 
requirements  is  dependent  on  architectural  decisions. 

Every  software-intensive  system  has  a  software  architecture. 
Just  having  an  architecture  is  different  from  having  an 
architecture  that  is  known  to  everyone,  much  less  one  that  is  fit 
for  the  system’s  intended  purpose. 

An  architecture-centric  approach  is  critical  to  achieving  and 
implementing  an  appropriate  architecture. 
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SEI  Unique  Contribution 

The  SEI  work  in  software  architecture  technology  and 
its  associated  methods  are  notably  unique  in  their 

•  explicit  focus  on  quality  attributes 

•  direct  linkage  to  business  and  mission  goals 

•  explicit  involvement  of  system  stakeholders 

•  high-quality  published  materials  for  practitioner 
consumption 

•  grounding  in  state-of-the-art  quality  attribute 
models  and  reasoning  frameworks 
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Conclusion 

Software  architecture  is  critical  to  achieving  key 
product  qualities. 

Software  architecture,  product  line  practices,  and 
predictable  component  practices  hold  great  potential 
for  achieving  business  and  mission  goals  in  the 
development  of  software-intensive  systems. 
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Linda  Northrop 
Director 

Product  Line  Systems  Program 
Telephone:  412-268-7638 
Email:  lmn@sei.cmu.edu 

U.S.  mail: 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 

World  Wide  Web: 

http://www.sei.cmu.edu/ata 

http://www.sei.cmu.edu/plp 

SEI  Fax:  412-268-5758 
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